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REMARKS 

Claims 1-7, 10-19, 22-31, 34-36, and 40-44 are pending. 
Claims 8, 9, 20, 21, 32, 33, and 37-39 were previously cancelled 
without prejudice. Claims 1, 13, 25, and 4 0 are independent 
claims. Reconsideration and allowance of the above -referenced 
application are respectfully requested. 

Claims 1, 2, 13, 14, 25, and 26 stand rejected under 35 USC 
102(e) as allegedly being anticipated by Peyravian et al . (US 
2004/0158715), hereinafter "Peyravian." Claims 6, 7, 10, 18, 
19, 22, 30, 31, 34, and 40 stand rejected under 35 USC 103(a) as 
allegedly being unpatentable over Peyravian. Claims 3-5, 11, 
12, 15-17, 23, 24, 27-29, 35, and 36 stand rejected under 35 USC 
103 (a) as allegedly being unpatentable over Peyravian in view of 
Schneier, ("Applied Cryptography," 2nd edition, pages 38-41 and 
146), hereinafter "Schneier." Claims 41-44 stand rejected under 
35 USC 103 (a) as allegedly being unpatentable over Peyravian in 
view of Palekar (US 2003/0226017), hereinafter "Palekar." The 
rejections are respectfully traversed. Peyravian, Schneir, or 
Palekar, taken alone or in any combination, do not describe or 
suggest all the features of the claimed subject matter. 

Claim 1 relates to a method of integrating a device into a 
secure network. A tunnel is established between an 
authenticator in the network and a device, where the tunnel uses 
a tunnel protocol. The authenticator has a first public key, 
while the device has a second secret and a second public key. A 
first hash is generated for transmission to the device. 
Further, the first hash is generated using a secret obtained 
from a user, the first public key, the second public key, and a 
random number generated from the tunnel protocol. The first 
hash is compared with a second hash generated at the device. 
Upon determining that the first hash matches the second hash, an 
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authenticated session is established between the device and the 
authenticator . 

The Office contends that Peyravian describes all the 
features described in claim 1. This contention should be 
reconsidered because Peyravian does not support the rejection. 
Peyravian describes a method to exchange and authenticate public 
cryptographic keys between parties that share a common but 
secret password. See, Peyravian at Abstract. 

The Office contends that because the claims do not require 
the secret, as claimed, to be transmitted to the device, the 
fact that Peyravian' s already knows the password is irrelevant. 
See, e.g., Office Action, page 2, 1 st paragraph. This contention 
should be reconsidered. The claimed subject matter relates to 
generating a first hash , where, in order to generate the first 
hash for transmission to the device, a secret is obtained from 
the user . Further, Applicant's remarks are not directed to 
whether or not the secret has to be transmitted to the device. 
Rather, Applicant's remarks establish that because Peyravian' s 
client and server know the password a priori, Peyravian does not 
describe generating the first hash using a secret obtained from 
a user as claimed. Consequently, Applicant's remarks establish 
that Peyravian' s password is not the secret, as claimed. 

Furthermore, Applicant fails to understand how the fact 
that Peyravian' s server already knows the password can be 
irrelevant when this fact is critical to distinguishing 
Peyravian' s hash generation from hash generation as claimed. 
Because Peyravian' s server already knows the password, when 
Peyravian' s server generates a hash for transmission to the 
client, the server does not obtain a secret from a user . In 
contrast, as claimed, the first hash generated for transmission 
is generated using, in part, a secret obtained from the user. 
Thus, the fact that Peyravian' s server already knows the 
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password is not irrelevant. On the contrary, it establishes 
that Peyravian does not describe "generating a first hash," as 
claimed. 

As discussed previously, claim 1 describes generating a 

first hash for transmission to the device including, in part, 

using a secret obtained from a user . In support of the 

contention that Peyravian describes this feature of claim 1, the 

Office Action states: 

The client concatenates the public key of the 
client, the public key of the server, and a random 
number ([0038 & [0040]), which is then hashed by the 
client and transmitted to the server ( [0040] ) , which 
.meets the limitation of generating a first hash for 
transmission to the device, the first hash generated 
using a secret obtained from a user, the first public 
key, the second public key, and a random number 
generated from the tunnel protocol . 

See, Office Action, page 3, last paragraph - page 4, 1 st 
paragraph . 

Thus, the Office appears to contend that because 
Peyravian' s client concatenates the public key of the client, 
the public key of the server, and a random number, and because 
Peyravian' s client then hashes the concatenation, Peyravian 
describes generating the first hash, as claimed. This 
contention cannot be supported. 

Peyravian' s server concatenates the client ID, the Diffie- 
Hellman public key of the client, the prime modulus, the public 
cryptographic key of the server, the Dif f ie-Hellman public key 
of the server, and the Dif f ie-Hellman symmetric secret key, to 
provide an argument, and hashes the argument to provide a hashed 
value. See, e.g., Peyravian, [0035]. Further, Peyravian 
describes calculating the Dif f ie-Hellman public key of the 
client and the Dif f ie-Hellman public key of the server using a 
password (PW) . See, e.g., Peyravian, [0034], [0035]. 
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Furthermore, Peyravian describes distributing the password, PW, 

securely to the client and to the server. In this regard, 

Peyravian states "For example, the server may generate and send 

the pair (ID, PW) to the client using conventional mail, email, 

or telephone." See, Peyravian, [0033] . Thus, as described in 

Peyravian, the server and the client know the password a priori. 

See, e.g., Peyravian, [0011]. Because the password is known to 

both the server and the client, Peyravian certainly does not 

describe obtaining the password from the client to determine 

Dif f ie-Hellman public keys for the client and the server to for 

concatenating into an argument and generating the hash from the 

argument. At least for these reasons, Peyravian does not 

describe "generating a first hash for transmission to the 

device, the first hash generated using a secret obtained from a 

user, the first public key, the second public key and a random 

number generated from the tunnel protocol," as claimed. 

Also, in response to Applicant's remarks that Peyravian 

does not describe generating random numbers from the tunnel 

protocol, as claimed, the Office contends that the claims do not 

specify exactly how the random number is generated and how the 

claimed tunnel protocol is involved in the generation procedure. 

Further, the Office Action states: 

For the purposes of examination, the claim 
limitation has been interpreted using a broad but 
reasonable interpretation which would cover generating 
the random numbers for use with a tunneling protocol, 
which is shown by Peyravian (Abstract & [0016] & 
[0038] & [0040] ) . 

See, Office Action, page 1, 2 nd paragraph. 

Thus, the Office contends that the feature "a random number 
generated from the tunnel protocol," as recited in claim 1, has 
been interpreted using a broad but reasonable interpretation. 
The MPEP states "During patent examination, the pending claims 



5 



Attorney's Docket No.: 10559-851001 / P1S877 
Intel Corporation 

must be 'given their broadest reasonable interpretation 
consistent with the specification . ' ... The broadest reasonable 
interpretation of the claims must also be consistent with the 
interpretation that those skilled in the art would reach." 
(Emphasis added) . See, MPEP 2111. Applicant respectfully 
submits that the broadest reasonable interpretation consistent 
with the specification and consistent with the interpretation 
that those skilled in the art would reach for the claimed random 
number must take into account the fact that the claimed random 
number is generated using a tunnel protocol. The Office cannot 
disregard "the tunnel protocol" feature in "a random number 
generated from the tunnel protocol," as claimed, and reject 
claim 1 simply because Peyravian teaches a random number. 

If the Office maintains the rejection of claim 1, then the 
Office must establish that Peyravian teaches "a random number 
generated from the tunnel protocol ," as recited in claim 1. The 
MPEP describes that a claim is anticipated only if each and 
every element as set forth in the claim is found, either 
expressly or inherently described, in a single prior art 
reference. See, e.g., MPEP 2131. Therefore, to establish 
anticipation, the feature "a random number generated from a 
tunnel protocol," as recited in claim 1, must be found in 
Peyravian. Applicant respectfully submits that not only does 
Peyravian not teach "a random number generated from a tunnel 
protocol," as claimed, but also Peyravian does not describe 
"tunnel protocol," as set forth in claim 1. Contrary to the 
Office's contention, the cited portions of Peyravian (Abstract, 
[0016], [0038], [0040]) do not describe "a tunnel protocol." 

In this regard, Peyravian describes that a secret random 
number for the client is generated by the client or on behalf of 
the client. See, e.g., Peyravian, [0030], [0034]. Similarly, 
Peyravian describes that a secret random number for the server 
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is generated by the server or on behalf of the server. See, 

e.g., Peyravian, [0031], [0035]. Neither the cited portion nor 

any other portion of Peyravian describes that the random number 

for either the client or the server is generated by a tunnel 

protocol . 

Further, the Office Action states: 

... Peyravian discloses an authentication system 
between parties communicating over a SSL tunnel 
(Abstract & [0016] ) , which meets the limitation of 
establishing a tunnel between an authenticator in the 
network and a device, the tunnel using a tunnel 
protocol . 

See, Office Action, page 3, paragraph 4. 

The first cited portion of Peyravian (Peyravian at 

Abstract) does not describe any type of communication protocol. 

The second cited portion of Peyravian (Peyravian, [0016] ) 

describes Secure Socket Layer (SSL) applications as one method 

to provide secure transmission of identifiers and passwords to 

clients. The Office appears to contend that the SSL application 

to provide secure transmission of identifiers and passwords to 

clients is the tunnel protocol, as claimed. If true, then this 

contention cannot be supported. Peyravian states: 

For example, a banking user may receive his or 
her ATM-card and its associated password separately 
through the mail; the password is required to have at 
least a specified minimum number of characters. 
Perhaps more apropos to the present invention, 
however, banks, brokers, and others rely on these same 
general principles to provide secure transmission of 
identifiers and passwords to clients using Secure 
Socket Layer (SSL) applications. 

See, Peyravian, [0 016] . 

Thus, Peyravian describes SSL applications as an example to 
transmit identifiers and passwords to clients. Peyravian does 
not describe that SSL applications are tunnel protocols, as 
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claimed. Consequently, Peyravian does not describe a tunnel 

protocol as claimed. Because Peyravian does not describe a 

tunnel protocol, Peyravian certainly does not describe "a random 

number generated from the tunnel protocol," as claimed. 

In addition, the Office Action states: 

... if the first secret and the second secret are 
different then the first hash and the second hash will 
never match, which would render Applicant's invention 
useless. It is clear that the first and second 
secrets are intended to be the same secret, otherwise 
it would be completely pointless to use them to 
generate hashes that are being compared for 
authentication purposes. 

See, Office Action, page 2, last paragraph - page 3, 1 st 
paragraph. 

The Office Action refers to w a first secret," which is not 
recited anywhere in claim 1. Applicant respectfully submits 
that the Office has not responded to Applicant's remarks that 
the secret, as described in Peyravian, is not "the second 
secret," as claimed. Instead, the Office refers to features 
that are not recited in claim 1. 

Also, the Office Action states "... the claims do not require 
the device to "receive the password from the client.'" See, 
Office Action, page 3, 2 nd paragraph. The Office contends that 
the password, as described in Peyravian, is the second secret as 
claimed. Claim 1 recites, in part, "generating a first hash for 
transmission to the device, the first hash generated using a 
secret obtained from a user , " (Emphasis added) . Applicant 
respectfully submits that, contrary to the Office's contention 
and for reasons discussed previously, a secret is certainly 
obtained from a user. 

Thus, Peyravian does not describe all the features of claim 
1. Therefore, anticipation is not established. Accordingly, 
claim 1 should be allowable. Claims 2-7 and 10-12 should also 
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be patentable at least for similar reasons and for the 
additional recitations that they contain. 

Claim 3 depends from claim 1. Peyravian does not describe 
or suggest all the features of claim 3 for reasons similar to 
claim 1. Schneier does not rectify the deficiencies in 
Peyravian. In this regard, the cited portions of Schneier do 
not describe or suggest "the first hash generated using a secret 
obtained from a user , the first public key, the second public 
key and a random number generated from the tunnel protocol," as 
claimed. Therefore, the suggested combination of Peyravian and 
Schneier does not describe or suggest all the features of claim 
3. Accordingly, claim 3 should also be patentable. 

Claim 13 recites "establish a tunnel between an 
authenticator in the network and a device, the tunnel using a 
tunnel protocol, the authenticator having a first public key, 
the device having a second secret and a second public key; 
generate a first hash for transmission to the device, the first 
hash generated using a secret obtained from a user , the first 
public key, the second public key and a random number generated 
from the tunnel protocol ; compare the first hash with a second 
hash, wherein the second hash is generated at the device; and 
upon determining that the first hash matches the second hash, 
establish an authenticated session between the device and the 
authenticator." (Emphasis added). 

Claim 13 should be patentable at least for reasons similar 
to claim 1. Claims 14-19, 23, and 24 should also be patentable 
at least for similar reasons and for the additional recitations 
that they contain. 

Claim 25 recites "establish a tunnel between an 
authenticator in the network and a device, the tunnel using a 
tunnel protocol, the authenticator having a first public key, 
the device having a second secret and a second public key; 
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generate a first hash for transmission to the device, the first 
hash generated using the a secret obtained from a user , the 
first public key, the second public key and a random number 
generated from the tunnel protocol; compare the first hash with 
a second hash, wherein the second hash is generated at the 
device; and upon determining that the first hash matches the 
second hash, establish an authenticated session between the 
device and the authenticator . " (Emphasis added). 

Claim 25 should be patentable at least for reasons similar 
to claim 1. Claims 26-31 and 34-36 should also be patentable at 
least for similar reasons and for the additional recitations 
that they contain. 

Claim 40 recites "a display; memory; a processor configured 
to connect the product to a secure network by performing 
operations comprising: establishing a tunnel between an 
authenticator in the network and the product, the tunnel using a 
tunnel protocol, the authenticator having a first public key, 
the product having a second secret and a second public key; 
generating a first hash, the first hash generated using a secret 
obtained from a user, the first public key, the second public 
key and a random number generated from the tunnel protocol to 
produce a hash of the first secret ; comparing the first hash 
with a second hash, wherein the second hash is generated at the 
product; and upon determining that the first hash matches the 
second hash, establishing an authenticated session between the 
product and the authenticator." (Emphasis added). 
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Claim 4 0 is patentable at least for reasons similar to 
claim 1 and for the additional recitations that it contains. 
The Office concedes that Peyravian does not disclose a display 
for displaying the hashes and the shared secret, as claimed. 
Further, the Office appears to take Official Notice that it 
would have been obvious to add displays to Peyravian' s clients 
and servers to improve the client and server machines. See, 
e.g., Office Action, page 7, 1 st paragraph. Applicants disagree 
with the Examiner's contention unsupported by documentary 
evidence. In the absence of documentary evidence, the Examiner 
should only take official notice of facts asserted to be "well- 
known" if those facts are capable of instant and unquestionable 
demonstration as being well-known. The MPEP states: 

It would not be appropriate for the examiner to 
take official notice of facts without citing a prior 
art reference where the facts asserted to be well 
known are not capable of instant and unquestionable 
demonstration as being well-known. For example, 
assertions of technical facts in the areas of esoteric 
technology or specific knowledge of the prior art must 
always be supported by citation to some reference work 
recognized as standard in the pertinent art. 

See, MPEP 2144 . 03 (A) , (emphasis in the original). 

If the Office is relying on personal knowledge to support 
the finding of what is known in the art, the Office must provide 
an affidavit or declaration setting forth specific factual 
statements and explanations to support the finding. See 37 CFR 
1.104(d)(2). Accordingly, if the rejection is to be maintained, 
the Applicant respectfully calls upon the Examiner to produce an 
affidavit or declaration to support the alleged facts of which 
the Examiner has taken official notice. See 37 CFR 1.104(c) (2). 
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Claims 41-44 should also be patentable at least for similar 
reasons and for the additional recitations that they contain. 
For example, claim 41 depends from claim 40 and should be 
patentable for reasons similar to claim 40. Peyravian does not 
describe or suggest all the features of claim 4 0 for reasons 
similar to claim 1. Palekar does not rectify the deficiencies 
in Peyravian. 

Palekar describes that an authentication protocol can be 
used to establish a secure method of communication between two 
devices on a network. Once established, the secure 
communication can be used to authenticate a client through 
various authentication methods. See, e.g., Palekar at Abstract. 
Palekar does not describe or suggest "the first hash generated 
using a secret obtained from a user , the first public key, the 
second public key and a random number generated from the tunnel 
protocol to produce a hash of the first secret," as claimed. 
Therefore, the suggested combination of Peyravian and Palekar 
does not describe or suggest all the features of the claimed 
subject matter. Accordingly, claim 41 should also be 
patentable. Claims 42-44 should also be patentable at least for 
similar reasons. 
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CONCLUSION 



It is believed that all of the pending claims have been 
addressed. However, the absence of a reply to a specific 
rejection, issue or comment does not signify agreement with or 
concession of that rejection, issue or comment. In addition, 
because the arguments made above may not be exhaustive, there 
may be reasons for patentability of any or all pending claims 
(or other claims) that have not been expressed. Finally, 
nothing in this paper should be construed as an intent to 
concede any issue with regard to any claim, except as 
specifically stated in this paper, and the amendment of any 
claim does not necessarily signify concession of unpatentability 
of the claim prior to its amendment. 

In view of the foregoing amendments and remarks, Applicants 
respectfully submit that the application is in condition for 
allowance, and such action is respectfully requested at the 
Examiner's earliest convenience. 

Please apply any credits or additional charges to deposit 
account 06-1050. 
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